I have just built and staged

groovy-eclipse-compiler 2.9.2-01
groovy-eclipse-batch 2.4.3-01

These are available from codehaus staging repo:
https://nexus.codehaus.org/content/groups/staging/

I'll leave it there for a couple of days so if someone could test them out a little before I press the button to promote them to maven central that would be great.

Thanks,

Kris

Artefacts released to maven central closing

The update site works for me. I pasted the url into Eclipse's 'Install new software' dialog and it looks fine.

You can't download something from http://dist.springsource.org/release/GRECLIPSE/e4.3

Because it is not a website but an Eclipse update site. Eclipse knows how to access certain urls below that path to determine what stuff is there. But you can't point your browser at that url directly, or use a curl request to read something from it.

A better test than your curl request is, for example this:

kdvolder@lebun:~/git/groovy-eclipse$ curl dist.springsource.org/release/GRECLIPSE/e4.3/compositeContent.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<repository name="Groovy Eclipse Latest Release for Eclipse e4.3" type="org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository" version="1.0.0">
  <properties size="1">
    <property name="p2.timestamp" value="1416218899394"/>
  </properties>
  <children size="1">
    <child location="http://dist.springsource.org/release/GRECLIPSE/2.9.1/e4.3"/>
  </children>
</repository>

Note this works for this url but not for all update sites, there are different types of update sites, this one in particular is a 'composite' site pointing elsewhere.

If the problem for you is that, for whatever reason, composite sites do not work for you, then you can also try using the site it points to directly:
http://dist.springsource.org/release/GRECLIPSE/2.9.1/e4.3

> The pom deployed on central has the following dependency ...

You are probably talking about this pom right? http://central.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-compiler/2.9.1-01/groovy-eclipse-compiler-2.9.1-01.pom
I am not sure why the dependency is marked as 'optional'. It really is required since it contains the actual compiler. Without the compiler its not possible to compile groovy code.

We could make it a fixed version, but I think that will make it impossible for people to use a specific version of groovy-eclipse-batch .

Does it work if you specify the groovy-eclipse-batch dependency explicitly in your own pom? (e.g. as in this example code:
https://github.com/groovy/groovy-eclipse/blob/master/ide-test/pom.xml#L41

Note: Groovy-eclipse-batch artifact version follows the groovy compiler version that it wraps. So specifying this dependency in your pom is
really how you tell maven which version of groovy to use for compiling your groovy code. So it is probably a good idea to
always be explicit about this.

Well I am talking of the pom of this project, yes If it shouldn't be optional, I'd argue this is a different problem.

If you put a fixed version anybody can update to whatever version they want. The version that is specified is the one that this project indicates. Using such a range (i.e. 9.9.9) is abusing the range system anyway.

To be clear, I am not complaining about the fact I can't use a different version. I could if I want but I understand I shouldn't. I am complaining that this range leads to unnecessary snapshot resolutions. If you're working with 2.9.1-01 version of the project I see no reason why it should attempt to use a different version for the groovy-eclipse-batch dependency. As you said that dependency follows the groovy compiler version that it wraps so why aren't you aligning those versions in your pom?

Thanks!

> why aren't you aligning those versions in your pom

Because it actually wraps more than one version of the groovy compiler. (Each of the wrapped compiler versions is a separate bundle with same bundle-id but different osgi version).
Things are a bit complicated because there's two versions that matter, the version of groovy-eclipse and the version of the groovy compiler and groovy-all jar).

So every time we build 'groovy-eclipse-compiler', at the same time we produce compatible 'groovy-eclipse-batch' artefacts for several different versions of groovy.

Probably this is why it was specified as a version range.

But perhaps it would be good enough to just tie it to the latest version. Especially if you are right that users can still override it in their own pom.

> I could if I want but I understand I shouldn't.

I am not sure. I think you probably should. Actually when I use the groovy-eclipse-compiler plugin I always specify the batch dependency explicitly as I want to be in control of the groovy version used for compiling the code in our projects.

Anyway... the next time we put out groovy-eclipse-compiler and batch artefacts to maven central I will probably follow your advise and tie the latest groovy-eclipse-compiler artefact to the latest available groovy-eclipse-batch version that it is compatible with.

do you know when it's going to be fixed? I can see it goes on the codehaus snapshot repo which is really bad since it will eventually go away.

I have just built and staged

groovy-eclipse-compiler 2.9.2-01
groovy-eclipse-batch 2.4.3-01

These are available from codehaus staging repo:
https://nexus.codehaus.org/content/groups/staging/

In a couple of days they will be released to maven central. I have replaced the version range with a optional dependency on just current last version groovy-eclipse-batch

Hi Mauro,
The fix has been merged: https://github.com/groovy/groovy-eclipse/pull/95

Great news! I look forward to testing this.

Groovy/Grails Tool Suite 3.6.1.201408250824-RELEASE-e43

I don't know why, but CompileDynamic class is not treated as an annotation but as a regular class. That is why it is being removed.
I will keep digging.
If it is really a blocker you could use "@CompileStatic(TypeCheckingMode.SKIP)" instead.
Thank you for the report.

In Groovy the AnnotationCollector classes aren't real annotation classes. That's something how it's designed.

I'm using "@groovy.transform.CompileDynamic" as a workaround. That works and doesn't get removed when organizing imports.

PR for the issue is submitted https://github.com/groovy/groovy-eclipse/pull/92

Merged

GGTS 3.6.1

The problem can be simply reproduced if output folder for trait is not the default output folder of Eclipse project.

Hi Mauro,
That's true, I can reproduce it. Labeled as 'triaged'.
Thank you!

PR for the bug was submitted https://github.com/groovy/groovy-eclipse/pull/89 .

Merged.

Maybe the source of the problem is the same (and the fix may be common), but if you try to navigate to the referenced field in a map-style constructor call (i.e., in the GRECLIPSE-1775 example you place the cursor over "foo:" in RefactoringTest.doSomething() and hit F3 to navigate to MyBean.foo) nothing happens. Javadoc hover and F2 don't work either.

PR for the issue is submitted: https://github.com/groovy/groovy-eclipse/pull/90

Merged

Fix verified in 2.9.1.xx-201410031620-e44, thank you!

Tested running on openJDK 6 & 7, oracle Java 8, mint linux 17.

Actually there is a problem inside Groovy. Groovy compiler fails to compile code described above.

PR for the issue submitted: https://github.com/groovy/groovy-eclipse/pull/80

Merged.

2.3.3 Groovy compiler

I get the abstract error in the editor (not in the problems/errors tab) when implementing a trait, but it never goes away (clean doesn't help). Luna with Groovy-Eclipse Feature 2.9.0.xx-201407142235-e44-RELEASE.

Compiles and runs so it's an editor annoyance only.

Another failing case:

def b3 = new MyBean(foo: AnotherClass.doSomething())

then rename AnotherClass. That is, in this case the refactoring involves a class name, rather than a variable name.

Issue has been fixed and merged.

Fix verified in 2.9.1.xx-201408202052-e44 for both the original case and the one in the first comment. Thank you!

I just created a groovy-eclipse-batch 2.2.1-01 release. This is staged to codehaus staging repo.
I.e : https://nexus.codehaus.org/content/groups/staging/

I'm holding of on publishing this to maven central for a few days to give a someone a chance for testing.

Chris Hamilton asked for this release on greclipse mailing list. So Chris, hopefully you can try it out quickly and let me know if it works for you?

groovy-eclipse-batch 2.3.6-01 release also staged now. Should be compatible with groovy-eclipse-compiler 2.9.0-01.

Also holding of on publishing this to maven central for a couple of days to give someone a chance to test it.

I have been using groovy-eclipse-batch 2.3.6-01 in several projects for the last month. It works just as expected, so I believe it can be released to maven central.

This issue seems to have dropped between the cracks. But there is already a newer compiler out on central and soon there will be a 2.4.3 as well so I'll just close this one now.

After a bit of thinking I suspect this may be related to lack of recoverability in the groovy parser - that may be disturbing the ability to properly record dependencies. But needs some digging to confirm.

Groovy 2.3.4

Try to use a newer Groovy version (2.3.4 or newer). It might solve this error, since they put in some fixes regarding static compilation. I did not get this specific error when I wrote that use case....

Oh, I see now you're already using 2.3.4... that's strange... What about an even newer one (2.3.6 is out right now)? Does the groovyc fails in the same way? If so, you may open a bug against Groovy itself. Otherwise please note that some differences between plain Groovy and Greclipse compilation with regards to the use of with have been seen by myself in GRECLIPSE-1760, but it seems to be a different issues and I don't know whether it might be related to this in some way...

Sorry, just saw this is already fixed... I must be blind...

JDK7, Eclipse 4.3.2

I am also able to reproduce the same error from a simple JUnit test that tries to use java reflection to do this:

	public void testIt() throws Exception {
		Class<?> klass = Class.forName("org.eclipse.core.runtime.IPluginDescriptor");
		System.out.println(klass);
		Method[] methods = klass.getMethods();
		for (Method method : methods) {
			System.out.println(method);
		}
	}

This test is placed in a new eclipse plugin that only depends on the 'org.eclipse.core.runtime', bundle then it is run as a JUnit plugin test.
I run this test in the eclipse setup as described above (i.e. with repast and greclipse snapshot installed).

I tried running the above test in fresh copy of Eclipse 4.3.2 and I'm getting the same result.
So it appears that the problem is present in Eclipse even without installing greclipse or repaste.

Also looking at the original stacktrace, it appears it contains no greclipse code. As far as I can tell it is caused by the repaste builder using groovy and then groovy classloading and using reflection on stuff it gets from the runtime classpath of the plugin hosting the repaste builder.

So it looks to me there isn't much that we (i.e. greclipse) can do about this.

Interestingly, running the same test in fresh Eclipse 4.4 also fails in a very similar way, but with a different ClassNF exception.
java.lang.NoClassDefFoundError: [Lorg/eclipse/core/runtime/IPluginPrerequisite;

What I am unsure of is whether this problem is a problem with Eclipse (packaging of the 'org.eclipse.core.runtime' bundle) or not.
It seems a lot of Eclipse code is running on top of this bundle without any issue.

Perhaps the problem is with how the client bundle imports its dependency.

Interesting... running a test like this from my (same) test bundle actually works

	public void testMore() throws Exception {
		IPluginDescriptor pds = new MockPluginDescriptor();
		ILibrary alib = pds.getRuntimeLibraries()[0];
	}

So while there seem to be problems using reflection on the `IPluginDescriptor` class, implementing/using it is not a problem.

Closing. Doesn't appear to be a problem with Greclipse.

I have raised a bug with eclipse, maybe this is something that can/needs to be fixed in how eclipse packages these classes.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=439554

The link isn't there (we are in the midst of addressing that), but greclipse has happily been on 4.4 for some time:

http://dist.springsource.org/snapshot/GRECLIPSE/e4.4

The link is there now. Closed.

Hi Visiliy, maybe this is the best place to note that the page at http://groovy.codehaus.org/Eclipse+Plugin is still outdated with regards to the released version update site.

Also, version 2.9.0 here in JIRA is still denoted as unreleased.

PR for the issue is submitted https://github.com/groovy/groovy-eclipse/pull/62

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!

The bug is fixed and will be merged soon. Thank you, Mauro!

PR for the issue is submitted: https://github.com/groovy/groovy-eclipse/pull/71

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!

@TypeChecked also breaks proposals for static members

Fix verified in 2.9.1.xx-201408202052-e44 for both @CompileStatic and @TypeChecked. Thank you!

However please note I opened GRECLIPSE-1782 as a usability improvement.

Windows 7 sp1 x64, Eclipse x64 4.4

JDT core was upgraded in greclipse on 11 Jun - can you try a more recent snapshot than 27 May?

I was using the STS Groovy/Grails update site to install: http://dist.springsource.com/milestone/TOOLS/update/e4.4/ - this is currently version 3.6,0,m1 of STS

I've now tested using the http://dist.springsource.org/milestone/GRECLIPSE/e4.4/ update site and installed version 2.9.0.xx-201406270115-e44 and this fixes the compiler bug.

@Steven - Thanks for trying out a new version, I'm glad it works for you. And thanks for describing what versions you were picking up from where, that may help another user who hits it. STS 3.6.0 final isn't too far off with all the latest stuff folded in.

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!

this issue was opened on the wrong project.

Appears fixed by update of jdt core to c0f9341

Upgraded to JDT Core c0f9341 (the latest version as of yesterday)

Fix committed

I assume we'll do 2.3.1 under this bug, not 2.3.0

I've built and deployed new snapshot version of groovy-eclipse-compiler 2.9.0 and groovy-eclipse-batch 2.3.1 to codehaus snapshot repository.

Steve if you got a chance to try it please do.

I've compiled our code with Java 8 and latest snapshot versions. Our code compiled and all spock tests executed without any issues.

However, groovy 2.3.2 was just released and has a critical bug fix. https://jira.codehaus.org/browse/GROOVY-6808. Could you please update to use 2.3.2?

Thank you.

Any ETA on this?

Before we can do the maven bit... greclipse compiler itself needs to be update to 2.3.2.

EDIT: actually... it looks lie Andy did this silently already. I checked the bundle manifest in groovy23 bundle and it says '2.3.2'.

Let me try and get another snapshot for greclipse compiler and batch out to codehaus snapshot repo now. I'll post a update when its ready to try out.

New snapshots for groovy-eclipse-compiler-2.9.0 and groovy-eclipse-batch-2.3.2 should now be available on codehaus snapshot repo.
Please try them out.

Groovy 2.3.3 seems imminent. Changed the title of issue to 2.3.3.
Hopefully 2.3.3 will be the last of the 2.3.x line.
We should probably do 2.3.3 compiler support and maven repackaging to coincide with 2.9.0 release.

I agree.

However, I am now get the following error when attempting to compile using the groovy-eclipse-batch 2.3.2-01-SNAPSHOT:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project databaseUtil: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:3.1:compile: java.lang.NoSuchFieldError: suppressImportErrors
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-compiler-plugin:3.1

The error does not occur when I switch back to 2.3.1

Thank you

I didn't get that error, but the tests I have are very simple (in terms of the groovy code it compiles).

However, what this looks like is probably an incompatibility between API in the 'groovy-eclipse-compiler' and 'groovy-compiler-batch' artifacts.
Can you make sure to use 2.9.0 snapshot of the groovy-eclipse-compiler with the new groovy-compiler-batch?

If you already doing that, or you still get the error after doing that, then I will probably need a test case to figure out what the problem might be exactly.

It might also help to get a full stacktrace of the error so maybe running maven with -X option may show something that helps determine the exact place the 'incompatible API' call originates from.

For easy reference, here's an excerpt from pom.xml from one of the regression test that gets executed and seems to work with the currently deployed snapshots:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
				<version>3.1</version>
        <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.9.0-01-SNAPSHOT</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.3.2-01-SNAPSHOT</version>
          </dependency>
        </dependencies>
      </plugin>

To ensure we are using the same versions. The exact version of the artifacts the test ends up using (downloaded from codehaus snapshot repo) are:
groovy-eclipse-compiler 2.9.0-01-20140605.173410-11
groovy-eclipse-batch 2.3.2-01-20140605.173311-1

I cleared out my local m2 repository but I'm still getting the same error. I confirmed that my pom file settings and snapshot versions match yours.

My java version is "1.8.0_05"

I tried with maven 3.2.1 and 3.1.1 and got the same error

My project is a multi-module project.

Here is my debug output:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project databaseUtil: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-compiler-plugin:3.1:compile: java.lang.NoSuchFieldError: suppressImportErrors
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-compiler-plugin:3.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
[ERROR] urls[1] = file:/Users/paulsideleau/.m2/repository/org/codehaus/groovy/groovy-eclipse-compiler/2.9.0-01-SNAPSHOT/groovy-eclipse-compiler-2.9.0-01-SNAPSHOT.jar
[ERROR] urls[2] = file:/Users/paulsideleau/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch/2.3.2-01-SNAPSHOT/groovy-eclipse-batch-2.3.2-01-SNAPSHOT.jar
[ERROR] urls[3] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
[ERROR] urls[4] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.jar
[ERROR] urls[5] = file:/Users/paulsideleau/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
[ERROR] urls[6] = file:/Users/paulsideleau/.m2/repository/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar
[ERROR] urls[7] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[8] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-api/2.2/plexus-compiler-api-2.2.jar
[ERROR] urls[9] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-manager/2.2/plexus-compiler-manager-2.2.jar
[ERROR] urls[10] = file:/Users/paulsideleau/.m2/repository/org/codehaus/plexus/plexus-compiler-javac/2.2/plexus-compiler-javac-2.2.jar
[ERROR] urls[11] = file:/Users/paulsideleau/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar
[ERROR] urls[12] = file:/Users/paulsideleau/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
[ERROR] urls[13] = file:/Users/paulsideleau/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar
[ERROR] urls[14] = file:/Users/paulsideleau/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
[ERROR] urls[15] = file:/Users/paulsideleau/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[project>ssi:ssi-pom:4.480.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
import: Entry[import from realm ClassRealm[project>ssi:ssi-pom:4.480.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]

-----------------------------------------------------

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:180)
... 20 more
Caused by: java.lang.NoSuchFieldError: suppressImportErrors
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundEnvImpl.<init>(RoundEnvImpl.java:58)
at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:148)
at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:878)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:488)
at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4157)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1694)
at org.codehaus.groovy.eclipse.compiler.InternalCompiler.doCompile(InternalCompiler.java:84)
at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.internalCompile(GroovyEclipseCompiler.java:132)
at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.performCompile(GroovyEclipseCompiler.java:90)
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
... 20 more
[ERROR]
[ERROR] -----------------------------------------------------
[ERROR] -> [Help 1]

Please provide a sample project (or multiproject if that be the case). I have no idea where to start on debugging this. But getting a sample to reproduce it is one step in the right direction.

I understand if its hard

I'll have a poke around the stacktraces first. Maybe something obvious will reveal itself.

Okay... it looks like the problem is that our JDT patch for Eclipse 4.4, which was a snapshot of JDT from a little while ago is missing that field which is referred by the current 'apt' bundle.

The apis must have evolved after the JDT for e44 patch was created.

This is actually not just a problem for the maven support but really indicates a problem in greclipse that might surface even in the IDE use of the compiler.

Note: since I understand the problem now, I don't think you need to go through the trouble of attaching a sample project.

Raised issue to fix the JDT patch for e4.4
https://jira.codehaus.org/browse/GRECLIPSE-1743

Once that's done can make another attempt at building the maven support.

Groovy 2.3.3 has been released.

Just built / deployed new snapshots of groovy-eclipse-compiler (2.9.0-01) and groovy-eclipse-batch (2.3.3-01).
Please give them a try. See if they work better than the last attempt

It worked. All code compiled and all tests passed.

Thank you

When are we planning to release 2.9.0-01 ? Currently , we are using Java-7 and we want to migrate to Java8.

I would seriously like to be able to work with both Java 8 and Groovy in Eclipse. Is there any estimate on when this will be possible??

Currently the plan is for around the end of this month.

To clarify, my previous response was to SUKRIT's question.

> I would seriously like to be able to work with both Java 8 and Groovy in Eclipse. Is there any estimate on when this will be possible??

This is already possible with a snapshot of Greclipse 2.9.0 with the 2.3.3 compiler support, installed into Eclipse 4.4.RC2.

If you want a 'real release' you need to wait for Greclipse 2.9.0 release and Eclipse 4.4 release.

Oh. Thanks. So Eclipse 4.3 support won't happen? (Just checking..)

The 2.9.0 snapshot currently available does still have an update site which offers the combination of greclipse with Eclipse Java 8 patch for JDT on Eclipse 4.3.
But this "JDT Java 8 patch" really was only a temporary thing to bridge the gap to a proper release of Eclipse 4.4. You can still use that for a while but recommended to move to Eclipse 4.4 if you care about Java 8.

The 4.3 + Java 8 update site is here: http://dist.springsource.org/snapshot/GRECLIPSE/e4.3-j8

Do you require any more additional testing to mark this is as fixed?

Thank you

More testing won't hurt, but its not left open for that.

Its kept open because I will have to do another 'build' of this for the release.
Creating these artifacts is a partially manual process so its not part of a release build automatically.

Once do a 'release' build it would be nice to have someone test the staged artifacts before I push the button to send them to maven central though.

I am willing to test the staged artifacts

groovy 2.3.4 has been released. Should I create a new JIRA ticket to request support for it and/or is there any documentation on how to create the artifact by hand ?

Thank you

I've changed the issue title to '2.3.4'. I'll do a snapshot today with the 2.3.4 compiler as I updated the the greclipse compiler yesterday to 2.3.4.

> is there any documentation on how to create the artifact by hand ?

Yes, it is here:
http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+Maven+integration+developer+resources

Process is a bit clunky and error prone. Also before you can do this the greclipse compiler patch has to be updated, but I already did this yesterday.

2.3.4 batch compiler is now available as a snaphot from codehaus snapshot repo. Please test it

Thanks,

Kris

PS: I also put new instructions for doing the 'batch artifacts' build here:
https://github.com/groovy/groovy-eclipse/wiki/Building-Maven-Batch-Compiler

Looks good. Our project built fine and all tests passed.

Thank you for the quick update and the documentation that you provided.

Okay thanks. You guys will be the first ones to hear this

The Greclipse 2.9.0 is about ready to release. The build is done and the maven artifacts are also built and staged here:

https://nexus.codehaus.org/content/groups/staging/

Before I press that button to release to maven central, it would be great if someone could test these once more. Paul you up for that?

groovy-eclipse-compiler version: 2.9.0-01
groovy-eclipse-batch-version: 2.3.4-01

If all goes well Greclipse 2.9.0 will release by the end of this week.

Kris

Yes, I will be able to test this evening.

Thank you

I think we are all set. All classes compiled and all unit tests passed.

Thank you

Great! Thanks Paul.

How soon until this is released to maven central?

Congrats on the release.

Thank you

I already released the artefacts from codehaus staging to maven central, but it may take some time before they show up.
I would have expected they should be there already now, but it seems they are not (just checked).

If they don't show up in a couple of days maybe something went wrong. So please ping this issue again
to get my attention.

Actually, it looks like the artefacts are on central already, they just don't show up yet in here http://search.maven.org/
I guess this index takes more time to pick up new artefacts than the actual repository.

But I was able to download new groovy-eclipse-compiler and batch artefacts to my local maven cache from central:

• http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-batch/2.3.4-01/groovy-eclipse-batch-2.3.4-01.jar
• http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-eclipse-compiler/2.9.0-01/groovy-eclipse-compiler-2.9.0-01.jar

Kris

I tweeted sonatype ops and they are reindexing. They indicated it should be searchable in the next 1-2 hours. https://twitter.com/sonatype_ops/status/490182024431280128

New versions of artifacts were deployed to staging:
https://nexus.codehaus.org/content/groups/staging/org/codehaus/groovy/groovy-eclipse-batch/2.3.7-01/
https://nexus.codehaus.org/content/groups/staging/org/codehaus/groovy/groovy-eclipse-compiler/2.9.1-01/

Windows 7 x64
Eclipse Kepler SR2 for JEE Developers

You should re-raise this issue on the correct project (SONAR, not GRECLIPSE).

Closing as 'Not a Bug' (not a Greclipse bug anyways).

Sorry for raising it in the wrong project.

Maven 3.2.1

It looks like the bug can be reproduced if all classes are in the same project, not only if there is maven dependency.

And it is probably not groovy-eclipse plugin bug, because it can be reproduced without eclipse at all. Just build "dep" and "main" with maven. And then try the following command:
mvn exec:java -Dexec.mainClass="bug.Main"

The result will be:
Found: null

That means the annotation is lost.

The maven build of the test case uses the groovy-eclipse-compiler as groovy compiler. If switched to groovyc with the maven ant-run plugin (as documented here http://groovy.codehaus.org/Compiling+With+Maven2), then the annotation is not lost. With all the classes in the same maven project, and building with maven (with the groovy-eclipse-compiler), then the annotation is not lost either.

It seems that this fix causes a deadlock in GGTS 3.6.2: https://issuetracker.springsource.com/browse/STS-3980

As far as I know it is normal behavior of Eclipse to add imports for @link JavaDoc tags. And it does not look like specific Groovy-Eclipse plugin issue. So it's probably better to contact Eclipse IDE development team.

> As far as I know it is normal behavior of Eclipse to add imports for @link JavaDoc tags

I think that is true, but is it also the case that Eclipse would/should generate warning messages for those imports then?
I don't think eclipse with pure Java does that. If so then this bug is valid since the problem is that the groovy compiler is not aware of the use of the type in Java/Groovy doc.

Okay I see now, the error is coming from Maven build rather than Eclipse build. It seems this behavior is indeed consistent then with how Eclipse Java compiler behaves. So I agree with Denis assessment this isn't really bug to fix in Greclipse.
It is rather an inconsistency between how Eclipse <-> maven treats type references in Java / Groovy doc.

In addition to the specs, you can find more tests here: https://github.com/groovy/groovy-core/blob/master/src/test/org/codehaus/groovy/transform/traitx/TraitASTTransformationTest.groovy

The first big PR from Denis is in, I think he is going to add a few incremental compilation tests (as opposed to batch compilation tests) and then we are done.

Second PR is in, which included incremental tests.

I am reopening it because last pull request had to be reverted because of using Eclipse 4.4 only API.

There's a new pull request from Denis here:

https://github.com/groovy/groovy-eclipse/pull/57

Pull request was merged, so I guess this could be closed?

Windows 7

The fix was https://github.com/groovy/groovy-eclipse/pull/29
Are there any tests left not passing on Win?

Yes, three tests left: one is about key bindings conflicts on startup and another two are about line wrappings, for example, if you format this piece of code

def gender = ["unknown",
"female",
"male"]

it is expected to get

def gender = ["unknown", "female", "male"]

but what you really get is

def gender = [
	"unknown",
	"female",
	"male"
]

This behavior takes place not only in tests, but in the application too.

Here are the names of the failing tests:
ErrorLogTest#testNoWarningsOnStartup()
Formatter_Test_List_formatting_bug_827.txt
Formatter_Test_List_formatting_for_fields.txt

Pull request successfully merged https://github.com/groovy/groovy-eclipse/pull/60

Fix commit of org.codehaus.groovy23 has been made - based on 2.3.0-beta-1 tag.

In case it helps this the code where I got the error (although I only got it once and can't reproduce it now).

package mojoa

import grails.transaction.Transactional
import groovy.json.JsonBuilder



@Transactional
class FooService {

    def gogog() {
		def builder = new JsonBuilder()
		builder.person {
			name "Kris"
			lastName "De Volder"
		}
		return builder.content.toString()
    }
}

The error happened when completing 'JsonBuilder'.

Using a build from source off GitHub, based on E4.3SR2.
Using the Groovy 2.1.x compiler.

Resolved in 2.9.1... GGTS 3.5.1

Jeff's sample projects.

Raised priority to critical based on input from Jeff Brown: "It is a big deal for anyone who wants to build a Grails 2.4 app in the IDE and wants to use @GrailsCompileStatic (or any other annotation marked with @AnnotationCollector)."

Related issues:

• GRECLIPSE-1586
• GRECLIPSE-1679 (closed as duplicate)

Previously I mentioned "I also get the same error if I move the code into a single project.".
As I am trying to reproduce again, this is not true (any more?).

I need the annotation to be defined in a separate project to get the error message.
Seems consistent with: GRECLIPSE-1679

I pushed a fix.
The fix is applied to e43j8 and e44 versions of JDT patch only.

This fixes the compilation error, but I now have a problem that I loose imports for AnnotationCollector annotation classes when I do organize imports. Auto-importing those classes don't work either. It's easy to reproduce the problem with groovy.transform.CompileDynamic annotation.

Please create a new issue ticket for this and include a code example to reproduce.

I reported GRECLIPSE-1794

It looks to me that the issue is that Greclipse IDE is not showing the issue in the problems view, i.e. not creating a resource marker and such rather than erroneously showing a problem after a project clean. The error is there even if all projects are cleaned or the rest project is cleaned. The difference is that it's not shown in the problems view and there are no error annotations on the Groovy resource.

In AbstractLinkingRenderer.groovy:

"Renderer<T> htmlRenderer" should be there rather than "Renderer htmlRenderer" for the htmlRenderer variable declaration. The Groovy syntax error seems legitimate to me.

The code should be:
final void render(T object, RenderContext context) {
final mimeType = context.acceptMimeType ?: getMimeTypes()[0]
context.setContentType( GrailsWebUtil.getContentType(mimeType.name, encoding) )

def viewName = context.viewName ?: context.actionName
final view = groovyPageLocator?.findViewForFormat(context.controllerName, viewName, mimeType.extension)
if (view) {
// if a view is provided, we use the HTML renderer to return an appropriate model to the view
Renderer<T> htmlRenderer = rendererRegistry?.findRenderer(MimeType.HTML, object)
if (htmlRenderer == null)

htmlRenderer.render(object, context)
} else

}

Looks like the syntax error is erroneous rather than problem marker not created.
The workaround for the issue is still Renderer<T> htmlRenderer
Couldn't create a minimal sample code to reproduce the problem. Created something very similar but the syntax error is not generated.

Observations:

1) If the following if block is commented out than syntax error is gone.
if (htmlRenderer == null)

Has to do something with Renderer htmlRenderer declaration line and htmlRenderer conditional assignment to DefaultHtmlRenderer.

2) MethodExpressionCall for "htmlRenderer.render(object, context)" has
Compilation: GenericsType is ImmutableClassNode for java.lang.Object (works in this case)
Reconcile: GenericsType is ClassNode for java.lang. Object that has a redirect to ImmutableClassNode for java.langObject - Syntax Error generated in this case

Problematic is static compilation that is triggered by the presence of @CompileStatic annotation on the AbstractLinkingRenderer class. Seems like static compilation generates the groovy syntax error erroneously. Furthermore, if static compilation produces an error the problem marker is created only for the resource modification.

Removing @CompileStatic annotation would also be a workaround.

It isn't uncommon for that to be a workaround. It does suggest that the ClassNodes being built by us just don't match those that groovy would be building in the same circumstance. If you had a reproduceable compile setup I'd say compile it inside and outside of eclipse (command line), debug both and compare the data structures involved to spot the difference. I'm still suspicious of that code that copies the groovy Java5 type behavior.

I'm not entirely sure that this issue is the same that I have, so I thought of commenting here to check first instead of raising a new issue.
I have a problem running the latest GA versions of Kepler or STS with latest Groovy plugin from Eclipse Marketplace.

I have a workspace with a single Groovy project and a bunch of Java projects. Two of those Java projects also have aspects and use the AspectJ nature. They are all maven projects, configured in Eclipse automatically with m2e and the Spring AspectJ Configurator.

When I first install Groovy plugin, everything works fine for a couple of days, I don't know exactly which event triggers the problem, but after that my projects that have AsepctJ nature stop outputting compiled classes to target/classes folder, in fact they seem not to compile anything at all to any folder, target/classes is always empty.
When I look at the project configuration everything seems to be fine with the Java Build Path and target output folders.

When I remove the Groovy plugin they start compiling as expected again. Once more, the projects that start having problems DO NOT have Groovy nature, only Java and AspectJ natures.

Please let me know if this should be a separate issue.

Think what you've described is a different issue from this one. This one is a static compile issue. Noticing this issue is a bit difficult because the error marker isn't always created for Groovy syntax error occurred during the static compilation. Yet the error is always there and can be observed once the groovy file is opened in an editor
Your issue is something rather different. I'd recommend you creating a sample little project on which the issue can be reproduced and attaching this project to the JIRA. Eclipse, Groove Eclipse, Groovy compiler and Java versions would be important to know too.

Turns out that our Groovy version for Groovy-Eclipse requires changes made to ClassNode in Groovy 2.x
https://github.com/groovy/groovy-eclipse/pull/44
Tested with Grails-Core, sample projects and Greclipse unit tests. Ran build locally and installed into Eclipse 4.3.2 and STS 3.5.1 via a local update site and performed the tests above.

Delivered the fix for 2.9.0

PR for the issue: https://github.com/groovy/groovy-eclipse/pull/18

PR committed. Testcase added too BasicGroovyBuildTests.

Fixed!

Can you please fork this repository git repository https://github.com/groovy/groovy-eclipse and submit your patch as a pull request? This way based on your contributions you could become a committer.

Your patch has been delivered.

Sorry, I was intending to create the pull request - just a busy week. If pull requests are the preferred mechanism for patches, I will certainly do that in the future.

Hmm... for some reason I'm not getting issue... I've tried GGTS 3.5 RC1 and the corresponding dev environment... all on 4.3.2 Kepler... Doesn't seem like i'm getting it.

I saw this though:
java.lang.NullPointerException
at org.codehaus.groovy.antlr.parser.GroovyLexer.require(GroovyLexer.java:300)
at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_CTOR_END(GroovyLexer.java:2364)
at org.codehaus.groovy.antlr.parser.GroovyLexer.mSTRING_LITERAL(GroovyLexer.java:2028)
at org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:459)
at org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:249)
at org.eclipse.jdt.groovy.core.util.GroovyScanner.nextToken(GroovyScanner.java:60)

after pressing enter at the end of the line, but this is unlikely to be critical, but a minot annoyance. I doubt however that what I'm seeing is the same as the reported issue.

Can you clarify perhaps the instructions on reproducing this problem? I've tried pressing 'Enter/Return' key right after the comma in '~"(?i)^sometext$", and was hoping to get a failure on putting an indent before the next string, but string is offset correctly. Tried writing groovy code outside of 'doThis(XXX) and the indent is such that everything is aligned with parameters of doThis. Is that the issue? (Not getting the same exception though)

I'm using Eclipse Java EE IDE for Web Developers, Kepler 4.3.2, with the Groovy-Eclipse plugin installed.

Create a new Groovy Project, Add "Bug.groovy" to the project.
Any line below '~"(?i)^sometext$", // SMART TAB FAILS AFTER HERE.' is where the tabbing fails.

Apologies, I'm used to posting in the Eclipse Bug System, where the Eclipse Config file is everything you need to know about a user's environment.

Alex pull request merged. Closing issue.
https://github.com/groovy/groovy-eclipse/pull/12

Adam, would you mind checking the code out of from Groovy Eclipse Git: https://github.com/groovy/groovy-eclipse/ and see if this issue is fixed there for you? Thanks in advance.

Please try Groovy Eclipse from this update site here: http://dist.springsource.org/release/GRECLIPSE/e4.3/ See if this issue is resolved.

Yes, that worked. Using Groovy-Eclipse Feature 2.9.0.xx-20140307-1300-e43-SNAPSHOT from the SHAPSHOT. The Release url is still on 2.8.0.

Thanks!

All fixed up. Combination of two things:

• source location processing for type annotations was not coping with synthetic arguments
• some 'smarts' in the content assist proposal computation was adding in the ';' if it looks like nothing could follow the selection. We don't want that for groovy.

Done. The first pass is to a JDT core that is not quite their RC2 - so we'll need to do another pass to pick up the latest fixes before release.

Possibly serious change due to this I had to prevent some of the tidyup for lookupenvironment/typesystem because some of the content assist type inference code is using it after it would normally have been tidied away. I'm assuming although tidyup doesn't happen it will be GC'd later when orphaned.

I have done the patch since 2.2.0, first pulling in changes from Groovy core from 2.2.0 -> 2.2.1 and then from 2.2.1 -> 2.2.2.
This is just waiting for a final review when any potential last minute changes from 'upstream' when Groovy 2.2.2 is officially released.

Groovy 2.2.2 is now official:
http://groovy.329449.n5.nabble.com/ANN-Groovy-2-2-2-td5718598.html

OS: Windows, Linux
Eclipse: Build id: 20130919-0819
Groovy-Eclipse plugin: Version: 2.8.0.xx-20130703-1600-e43-RELEASE

Might be worth pointing out: for pure Java class, the Outline view works just fine.

I think it is worth trying a greclipse dev build - we had this problem with an empty outline a while ago, I'm just not sure if the fix made it into 2.8.0 or not.

I installed Version: 2.9.0.xx-20140116-1400-e43-RELEASE from http://dist.springsource.org/snapshot/GRECLIPSE/e4.3/ That seems to have fixed the problem.
How do I know when this will make it into the stable release. I generally do not need the cutting edge stuff, I just need my stuff to work. :-\
Thanx!

Groovy-Eclipse plugin

Version: 2.9.0.xx-20131205-1200-e43-RELEASE
Groovy version: org.codehaus.groovy

Please also note that when the closure is passed to a method (i.e. using each) on a method defined without the def keyword, then the action is available, but it lead to wrong results (it could be related to GRECLIPSE-1526).
If the closure is within a method defined with the_def_ keyword, then the action is not available.
Follows an example

class Foo {
    public void foo () {
        ['foo'].each {String s->
            s.bytes //  "Assign to new variable" action is available, but if used lead to wrong result
        }

// This would be the result of running "Assign to new variable" on the above statement 

//      def each = ['foo'].each {String s->
//          s.bytes //  "Assign to new variable" action is available, but if used lead to wrong result
//      }
    }
    
    def bar () {
        ['bar'].each {String s->
            s.bytes  // WRONG no "Assign to new variable" action (the method is defined with the "def" keyword)
        }
    }
}

This issue is quite similar to GRECLIPSE-1702 and they seem to have common solution.

Fixed by the following PR: https://github.com/groovy/groovy-eclipse/pull/56

Great news, thank you!

Fix verified in 2.9.1.xx-201408202052-e44. Thank you!